IBIS Macromodel Task Group Meeting date: 08 Nov 2011 Members (asterisk for those attending): Agilent: * Fangyi Rao * Radek Biernacki Altera: David Banas Ansys: Samuel Mertens Dan Dvorscak * Curtis Clark Arrow Electronics: Ian Dodd Cadence Design Systems: Terry Jernberg Ambrish Varma Celsionix: Kellee Crisafulli Cisco Systems: Mike LaBonte Ashwin Vasudevan Syed Huq Ericsson: Anders Ekholm IBM: * Greg Edlund Intel: Michael Mirmak LSI Logic: Wenyi Jin Mentor Graphics: * John Angulo Zhen Mu * Arpad Muranyi Vladimir Dmitriev-Zdorov Micron Technology: Randy Wolff NetLogic Microsystems: Ryan Couts Nokia-Siemens Networks: * Eckhard Lenski QLogic Corp. James Zhou Sigrity: Brad Brim Kumar Keshavan * Ken Willis SiSoft: Walter Katz Todd Westerhoff Doug Burns Snowbush IP: Marcus Van Ierssel ST Micro: Syed Sadeghi Teraspeed Consulting Group: Scott McMorrow * Bob Ross TI: Casey Morrison Alfred Chong Vitesse Semiconductor: Eric Sweetman Xilinx: Mustansir Fanaswalla The meeting was lead by Arpad Muranyi Minutes taken by Curtis Clark ------------------------------------------------------------------------ Opens: -------------------------- Call for patent disclosure: - None ------------- Review of ARs: - None ------------- New Discussion: Quick question from Ken regarding Backchannel BIRD status: - Ken: Backchannel BIRD was tabled in IBIS Open Forum. Next step? - Arpad: Pull it back here in ATM for review or stay in Open Forum. - Ken: Anymore feedback? What's left to do before acceptance? - Bob: I had syntax objections I'd raised privately. - Ken: What's the process to move forward? - Arpad: Feedback, discussion, then vote to have Open Forum move on it. - Ken: Okay, everyone please help by providing feedback. - Bob: After the upcoming summit. - Arpad: I haven't had time to give it a thorough review yet, but intend to do it soon. - Let's get email feedback to Ken, then we can discuss it. BIRD 140.1 Corner Clarifications: - Arpad: Start with the new BIRD (proposing Model_type restrictions) - Summarized previous meeting's decision to restrict the Model_type - new BIRD reduces number of parameters with corner mapping issues. - Very simple new BIRD as written. - Discovered a new issue, however. - 3-State Model_type should be restricted to AMI Tx. - But, I/O has same issue and no way to tell if AMI is Tx or Rx. - How do we know? - Should we address this ambiguity? - Arpad: Walter and Todd privately suggested a solution - Restrict Model_Types to Input, Output, Input_Diff, Output_Diff? - Arpad: This suggestions concerns me. What about ECLs for example? - Bob: Don't address it here. Leave it alone. - Address it in 5.2, not hurting anything to leave it alone. - Don't want more work for the parser. - Radek: I/O not really a problem. If enabled it's Tx, else Rx. - Arpad: No way to know if the [Algorithmic Model] is Tx or Rx. - Radek: Oh, the .dll name usually makes it clear what the model is. - Bob: Yes it's an issue, should not be resolved now, new parameter? - Arpad: Yes, agreed. Ultimately, we could add a selection parameter - Then have both Tx and Rx references in the same [Algorithmic Model]. - Bob: Would bi-directional AMI be a stretch? - Arpad: Yes, probably a stretch. - Would need selection of both Tx and Rx parameters. - defining the selection process would be a big effort. - Radek: Not a real ambiguity. Up to the user. - Bigger ambiguities in [Diff Pin] vs. differential buffer. - Arpad: Anyone opposed to moving on with the simple BIRD as is? - Do we need another review cycle - Wait, don't act on that question until we review other changes. Move on to changes in BIRD 140.1 itself: - Arpad: [Diff Pin] keyword, tdelay_*** values are ignored for AMI - Do we need more verbiage? - Radek: intent was to clarify tdelay_*** has no association with corner. - We should not force zero to be used at all times. - Arpad: this is just saying that tdelay_*** ignored for AMI channel characterization, normal simulations are not affected - Bob: Last meeting I had agreed with "just ignore" or treat as zero. - These weren't really "corners" they were delay tolerances. - Concern now is that this text should go under AMI not [Diff Pin]. - Any elaboration should also go in AMI. - Arpad: Partially disagree - [Diff Pin] user should immediately see tdelay_*** is ignored for AMI. - Bob: I guess I'd be okay with adding it in both places. - Radek: Agree with Bob, keep it separated in AMI. - Arpad: Open to suggestions. Move to next section/modification: - Arpad: for External Model/Circuit - "min" Model -> slow/weak - "max" Model -> fast/strong - Bob: Okay with [External Model] (buffers). - Not Okay with [External Circuit], might be passive interconnect. - Would represent "tolerance" not a "corner" in that case. - Arpad: isn't "long trace" -> slow corner? - Bob: yes, could be okay. - Radek: sounds fine - Bob: it might render all [External Circuit] parameter selection muddled. - Arpad: I always thought "min" and "max" kind of odd for External Model - this is actually more of a clarification. - Bob: This runs the risk of making [External Circuit] just another buffer. - [External Circuit] has a higher scope (outside Model) - strange to tie it to a model/buffer-centric parameter like typ. - Arpad: Issue is already muddled - if user wants all "slow" cases, shouldn't they be able to get slow? - slow package and slow buffer for a system analysis? - Bob: Using the same lingo, what's a strong/fast connector? (Ext Circuit) - Arpad: low impedance, fast propagation velocity... - Bob: Could depend, series vs. parallel termination, for example. - Arpad: an interconnect could be fast/slow from system design perspectives - everyone propose suggested text and I'll consider it. Move on to next section/modification: - Arpad: (revisiting the "implicitly aligned" section) - reiterate "typ/min/max" and reference section 9 on Data Derivation. - Bob: Changes are good, now acceptable for 5.1. - these changes avoid the problem areas we'd run into. - Fangyi: slow -> "Min", fast -> "Max", is this always true? - What about a jitter parameter? Minimum should be fast. - What about a Range parameter (AMI). - Arpad: A jitter parameter is an AMI Format Corner parameter, which doesn't require the to be smaller than - It would not need the linkage being defined here with old IBIS analog. - Radek: Fangyi is saying corner would force "slow" -> "Min" mapping. - What would Range do? We should address them together. - Arpad: disagree. AMI List/Range are explicitly independent of Corner. - Last sentence in paragraph is saying this. - Radek: there is a new ambiguity with Range. - Fangyi: Oh, I see (realizing the source of his confusion) - Could we make two things more explicitly clear? - Mapping AMI corner to legacy IBIS analog - AMI Range/List are independent of Corner. - Radek: Last sentence is insufficient to clear up Range ambiguity. - Bob: Range has an entirely different meaning (it's independent of corner) - Choosing tap coefficients, for example - Range/List are user tunable parameters - Arpad: I've added extra verbiage (showed the location) detailing these - Corner description - Range description Arpad: This has been a good discussion. - Those of you who have suggestions or made suggestions please email them. - Back to the previous question about proceeding with the new BIRD. - Let's go through one more review cycle with this discussion. Meeting ended. ------------- Next meeting: 29 Nov 2011 12:00pm PT (11/15 and 11/22 canceled due to IBIS Asia Summit) Next agenda: 1) Task list item discussions ------------- IBIS Interconnect SPICE Wish List: 1) Simulator directives